Skip to content

Conversation

@nsaccente
Copy link

This PR addresses issue 57. The original issue explains that attempting to use a Literal type annotation in a SQLModel raises a type error from issubclass. This is because Literal is not a class, but a typing._SpecialForm, so static funcs like isinstance and issubclass don't work with it.

The fix was pretty straightforward, I just added a check before an isinstance or issubclass would have been called that checks if type_ is Literal.

@nsaccente nsaccente changed the title Add check for Literal type annotation in get_sqlalchemy_type 🐛Add check for Literal type annotation in get_sqlalchemy_type Jul 24, 2025
@nsaccente
Copy link
Author

I have no idea how to add the proper labels to this PR, it looks like the permissions aren't set up to allow me to.

@YuriiMotov YuriiMotov changed the title 🐛Add check for Literal type annotation in get_sqlalchemy_type 🐛 Fix TypeError for fields annotated with Literal Aug 5, 2025
@YuriiMotov YuriiMotov added the bug Something isn't working label Aug 5, 2025
YuriiMotov

This comment was marked as outdated.

@YuriiMotov YuriiMotov linked an issue Aug 5, 2025 that may be closed by this pull request
8 tasks
@YuriiMotov YuriiMotov dismissed their stale review August 5, 2025 17:25

oh, wait...

@YuriiMotov
Copy link
Member

@nsaccente, thanks for working on this!
This works, but could you please add a test?

@nsaccente
Copy link
Author

@nsaccente, thanks for working on this! This works, but could you please add a test?

Sure. I'll try to get that done sometime this week.

@github-actions github-actions bot removed the waiting label Aug 6, 2025
@nsaccente nsaccente force-pushed the bugfix-57/literal-satype branch from 2aaef2d to 3c024e2 Compare August 16, 2025 01:32
@nsaccente
Copy link
Author

I've been fighting with getting the tests to work. I've been able to get things to pass in some versions of python, but not others. Any guidance on how to run these CI tests locally?

@svlandeg svlandeg marked this pull request as draft August 22, 2025 12:12
@svlandeg svlandeg self-assigned this Aug 22, 2025
@tiangolo tiangolo changed the title 🐛 Fix TypeError for fields annotated with Literal ✨ Add support for Literal types Sep 20, 2025
@tiangolo tiangolo added feature New feature or request and removed bug Something isn't working labels Sep 20, 2025
@tiangolo
Copy link
Member

I'm seeing that this assumes all Literal values are strings, so a model like this:

class Hero(SQLModel, table=True):
    id: Optional[int] = Field(default=None, primary_key=True)
    name: str = Field(unique=True)
    weakness: Literal[1, 2, 3]

...would still create the column in the DB as a string, not as an integer. 🤔

@YuriiMotov YuriiMotov self-assigned this Sep 30, 2025
@YuriiMotov
Copy link
Member

YuriiMotov commented Oct 1, 2025

Things are getting complex.. We can easily add special cases for Literal[1, 2, 3] or Literal[True, False] to create column with proper type.

The question is, do we expect any kind of validation for these values?
Our database column type is just CHAR or INTEGER, so, database will not enforce the value to be correct against Literal[1, 2, 3] type. If we have the value 42 in database, it can break user's code in a very tricky way one day

@YuriiMotov YuriiMotov dismissed their stale review October 1, 2025 15:16

Need to decide about data validation first

@YuriiMotov YuriiMotov removed their assignment Oct 1, 2025
@github-actions github-actions bot added the conflicts Automatically generated when a PR has a merge conflict label Dec 26, 2025
@github-actions

This comment was marked as resolved.

@github-actions github-actions bot removed the conflicts Automatically generated when a PR has a merge conflict label Dec 26, 2025
@github-actions github-actions bot added the conflicts Automatically generated when a PR has a merge conflict label Dec 28, 2025
@github-actions

This comment was marked as resolved.

1 similar comment
@github-actions

This comment was marked as resolved.

@svlandeg svlandeg self-assigned this Jan 13, 2026
@github-actions github-actions bot removed the conflicts Automatically generated when a PR has a merge conflict label Jan 27, 2026
@svlandeg svlandeg marked this pull request as draft January 27, 2026 10:09
Copy link
Member

@svlandeg svlandeg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I gave this some more thought and agree that this feature is more complex that it initially seemed. Just avoiding the crash when using Literal isn't sufficient: we also want to map to the right datatype ànd somehow respect the value restriction that the Literal definition presents.

Building on the changes by Yurii to identify all-bool or all-int columns, I've now also pushed another update that creates SQL constraints for the values in the Literal. This way, the data can't get corrupted and the user won't receive values that don't match the expected Literal definition.

Having mixed types in a Literal is still not ideal. I wonder whether we should support it by just making it all str (as the PR does now), whether we should reject it entirely (by raising an exception) or whether there is some other way we could deal with this 🤔

@YuriiMotov: would love a review from you on this!

@svlandeg svlandeg marked this pull request as ready for review January 27, 2026 12:55
@svlandeg svlandeg requested a review from YuriiMotov January 27, 2026 12:55
@svlandeg svlandeg removed their assignment Jan 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Variables with annotation of 'typing.Literal' causes a panic

4 participants